Generators cannot be reused (once exhausted, they're done). They are not ideal for random access or multiple-pass algorithms. They also cannot be used for async operations without a runner.

Generators are single-use; you cannot restart them. They lack random access (no [index]). They are not suitable for algorithms that require multiple passes over the data unless you regenerate the generator. They also do not natively support concurrency or parallelism; you need additional machinery (like a scheduler) for that.

Difficulty: 5/10

Topics: lazy evaluation, stateful iteration, concurrency limits

Scenario Questions

0-2 years experience

1
How would you use a generator to read lines from a large file without loading the whole file into memory? What happens if you try to iterate twice over the same generator instance?
2
If you call .next() on a generator after it has already returned {done:true}, what does JavaScript return?
3
Write a simple generator that yields the first N Fibonacci numbers. What limitation would you hit if you needed to restart the sequence without creating a new generator?

2-5 years experience

1
We have a function that streams API responses using a generator, but it started throwing errors when network latency increased. Why might a plain generator be a poor fit for this scenario, and how would you modify the implementation?
2
During a code review, a teammate replaced a for‑loop with a generator to improve readability, yet performance regressed. What aspects of generators could cause this slowdown?
3
Explain why using a generator to implement a cache that needs random access to previously yielded items is problematic.

5-8 years experience

1
Design a data‑processing pipeline that handles millions of records. Would you base it on generators, async iterators, or another approach? Discuss trade‑offs regarding back‑pressure, error propagation, and resource usage.
2
Our microservice uses a generator to produce events for downstream consumers, but we now need multiple consumers to read the same stream concurrently. What limitations of generators affect this, and how would you redesign the component?
3
When profiling a Node.js service, you notice a generator‑based iterator causing high CPU usage due to repeated context switches. Explain why generators may not scale well under high concurrency and propose an alternative.

8+ years experience

1
A legacy codebase heavily relies on synchronous generators for data ingestion, and we now need to migrate to a distributed streaming platform like Kafka. What architectural challenges arise from the generator model, and how would you plan the migration?
2
Across several teams, generators are being used as a substitute for async streams, leading to inconsistent error handling and back‑pressure semantics. As a staff engineer, how would you establish guidelines or refactor the system to address these issues?
3
Consider a long‑running server that keeps a generator open for hours to serve client‑side pagination. What risks does this pose for memory leaks and state consistency, and how would you redesign the API to be more robust at scale?

Follow-up Questions

❓What tooling or metrics would you use to spot generator‑related performance issues in production?
❓If you had to refactor a generator‑based API to support multiple consumers, what pattern would you choose?
❓Can you give an example where the lazy nature of a generator could introduce a subtle bug?